A server may download an application into the client environment in order to perform a variety of tasks as well as typically to send data back to the server. Examples of such downloaded applications include Flash™ applications, Java™ applets, and ActiveX™ controls. Some of these applications (notably Flash and Java) run with a limited set of privileges, ostensibly so that they will not do damage to the client machine on which they are running, although exploits have occasionally been found (see for example, “Application-Specific Attacks Leveraging the ActionScript Virtual Machine.” Mark Dowd, IBM Internet Security Systems which is available at http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf). Downloading applications dynamically (as in the case for Flash and Java) for each use ensures that the application is always up to date, assuming caching is disabled. As a result, version control issues are significantly reduced. The tradeoff is that time is spent downloading the application each time it is used; however, bandwidth issues have been greatly mitigated with the widespread adoption of broadband Internet connections.
Communications between a client application and the server from which it was downloaded often involve sensitive information and, as such, should be secure. For example, downloaded applications typically have access to small portions of the file system of the client computer. One such example is a cookie—see “HTTP State Management Mechanism.” Internet Engineering Task Force Request for Comments 2965, which is available at http://www.faqs.org/rfcs/rfc2965.html). Another example is Flash's Shared Object storage mechanism—see “Local Shared Object.” Wikipedia http://en.wikipedia.org/wiki/Local_Shared_Object. These storage mechanisms can be used to store client-specific data, which can potentially be of sensitive nature. The data may be encrypted, and a server may need to ensure that only applications it has recently downloaded (and which therefore are trusted) are given decryption keys.
As a result, it is normally desirable for the server to attempt to authenticate the source of communications to it. Authentication of the specific code is often an implicit assumption made by the server. For example, in a Java environment running inside a browser, the sandbox security model ensures that downloaded code can only communicate to the server host that the code originated from. Flash has similar restrictions. Some applications assume the converse: if communication to the server is occurring, it must be from a genuine applet. Such applications can be fooled by programs that simulate the downloaded application's messages.
The current state of the art for application authentication typically involves either digitally signing the application (and expecting the browser to validate the signature, especially in the case of privileges required outside of the standard sandbox), or the use of client-side public key certificates to authenticate installed client-side code to the server. See for example, “Public Key Infrastructure” Wikipedia, which is available at http://en.wikipedia.org/wiki/Public_key_infrastructure. Insofar as digitally signed applications are concerned, the main objective is to protect the client machine. In effect, if the application is not digitally signed as required, the user should not trust it.
To ensure the integrity of the code that is connecting to the server, the server may require a client certificate for secure communication. A client certificate is typically used to authenticate the browser to the server, rather than authenticating the specific application to the server. Such certificates contain a public key that is paired with a private key. The public key identifies the owner of the certificate and is used for key exchange, while the private key is used to generate the public key, and, in practice, to prove that the public key is controlled by the owner. The private key is typically protected by a password. The security of such a system rests with the strength of the private key and the means used to secure it (e.g., not written down or hardwired into the computer). In addition, the public keys must be registered if one party is to have confidence in the identity of the other party.
An application could also utilize an embedded client certificate to make a secure connection to the server. However, it is more computationally expensive to do so using public key cryptographic operations since these take significant time to evaluate. Furthermore, the certificate could still be extracted from the downloaded code and used maliciously. Since certificates typically have a much longer lifetime than the downloaded code (again due to their expense), this remains a vulnerability for attack.
During communications between the server and the client requesting the downloaded application, the server may set a variety of session credentials, such as a session cookie—that is, a cookie that does not persist after the client browser is shut down—or other data stored in other browser code. The setting and subsequent sending of the session credentials in Request/Response messages may be governed by the client browser and the server, and not necessarily by the downloaded application itself. For examples, cookies are typically sent by the browser, even if a Flash SWF file or Java class file does not explicitly set them in the headers of a request to the server.
As described below, a variety of attacks are possible with the above-described architecture.
For example, in a network monitoring attack, the attacker, who may be located at any intermediate router along the Internet, may monitor and possibly modify communications between the application and the server. The use of strong encryption such as SSL or TLS generally serves to mitigate this possibility.
Similarly, in a man-in-the-middle attack, the attacker may interpose itself between the application and the server making independent connections with each and relaying messages between them, thereby leading the application and server to conclude that they are communicating with each other over a private connection when in fact the entire conversation is controlled by the attacker. If secure communication involves the use of public key certificates, impersonation of the parties by way of such an attack can be made less likely.
Even with the use of SSL/TLS and public key encryption technology, other potential threats that stem from greater potential vulnerabilities remain. In particular, such potential attacks include: (i) Trojans aimed at the network stack: (ii) machine compromise coupled with reverse engineering/emulation of the application; and (iii) cross site reference forgery (XSRF) attacks. Each of these is described further below.
An attacker could fool a user into installing a Trojan, keystroke logger, or other such program that can eavesdrop on and intercept data. Trojans can be unwittingly installed on client devices when a user opens infected email attachments, as described in “PDF Exploit Spam Used to Install Gozi Trojan in New Attack,” Jackson, SecureWorks, available at http://www.secureworks.com/research/threats/gozipdf/?theat=gozipdf. Such programs generally appear to do something useful but also perform malicious actions—see “Reflections on Trusting Trust,” Ken Thompson, 1984, which is available at http://www.ece.cmu.edu/˜ganger/712.fall02/papers/p761-thompson.pdf. These programs may pose a significant threat even if they only possess the ability to read all network communications or all keystrokes (as opposed to being able to execute arbitrary code).
As a result, direct communication of keying information between the server and application can be risky, In particular, some of the more sophisticated Trojans, such as the Gozi Trojan, can inject themselves into the network protocol stack, for example by making use of the Layered Service Provider features of Winsock2 to actually intercept SSL/TLS data at a point before it is encrypted. See “Gozi Trojan,” Don Jackson, SecureWorks, which is available at http://www.secureworks.com/research/threats/gozi/. If the server is providing sensitive data (such as encryption keys for data stored on the client), the data may not be safe. Furthermore, such generic attacks can gain access to a broad number of client machines with minimal effort.
With the second more serious threat mentioned above, a client machine may be compromised if an attacker successfully obtains root access to it and can execute arbitrary code on the client enabling the attacked to make arbitrary network connections. The attacker can then download the application from the server, reverse engineer it, and then alter the application to record the sensitive data such as encryption keys and to give the application further privileges, including the ability to communicate with arbitrary hosts. After installing the modified application on a client, the attacker uses this modified application to connect to the server, with the server assuming the code is legitimate because the required protocols are observed.
Finally, in a cross site reference forgery (XSRF) attack, another application may send a message to the server, taking advantage of the fact that the session credentials are stored in the browser for as long as it is open. Such an attack is described in “Cross Site Reference Forgery: An introduction to a common web application weakness.” Jesse Burns, Information Security Partners, LLC. 2005, which is available at http://www.isecpartners.com/documents/XSRF_Paper.pdf. For example, if a user is logged into his brokerage account, and then surfs to a malicious newsgroup without first logging out of the brokerage system, the malicious newsgroup site could use JavaScript to issue commands to the brokerage via HTTPS URLs, and thereby could requests identical to what the browser would send in response to the user's interaction on the broker's actual site, and thereby manipulate the account (transferring money, making trades, etc.). Burns describes several techniques to help reduce the chance of XSRF attacks. One such technique involves passing cryptographic tokens in a URL response that are required to be sent back to the server in the next request. In effect, the security tokens (which an attacker should, of course, not know) are embedded in HTML code in the browser. However, HTML is easy to parse, and if the network stack is compromised, an attacker will be able to obtain these tokens. It is therefore not unreasonable to assume that for high-value transactions, the combination of network compromise and token replay will be attempted.
The above attack threats must also be tempered by the continual trade-off between user convenience, user knowledge and system security. For example, if client code is permanently installed on the client machine, it would be possible to install a public key certificate and a corresponding private key. However, many users are wary of installing code on their machines, which would limit the access or adoption rate of the network application. Furthermore even for those who choose to install, few will understand the concept of PKI and therefore the need for a password to protect the private key. Moreover, passwords are often forgotten, and if the system is truly secure and has no back door facility, sensitive data could be lost.
For these reasons, conventional network application security tends not to use such client-side certificates, but rather to create services that the user logs into, such as online banking and e-commerce shopping accounts. Keystroke logging attacks may be mitigated by using various graphical methods (see for example United States Published Patent Application No. US Patent Application 2006/0020815 entitled “Online data encryption and decryption.”). Anti-phishing technologies such as SiteKey (see “SiteKey” Wikipedia, which is available at http://en.wikipedia.org/wiki/Sitekey) and multi-site visual authentication schemes (see for example, U.S. patent application Ser. No. 11/850,805 entitled “System And Method For Verifying Networked Sites”) can also provide a user with a higher degree of confidence that he or she is dealing with an authentic site. Disadvantageously, however, these solutions require at least at some level user input or awareness.
In view of the above, there remains a need for a system and method capable of providing communications between a server and a client application downloaded from that server in a computationally efficient, up-to-date, and highly secure manner and without requiring any input or awareness on the part of the user of a client device.